TCP is one of the most widely used network protocols. Its most important feature is reliable ordered delivery. It is used by many network applications and services which require reliable data connections.
A wide set of application layer protocols which, as a whole, form the basis of today's WEB and networking use TCP as a transport layer protocol. Among them are: HTTP, FTP, mail protocols, data base remote access protocols. VPNs built on SSL use TCP as well. TCP is so popular and wide spread that most existing computer networks feature it. It has become so common that almost all (if not all) widely used operating systems have a built-in TCP implementations.
However, TCPs main weakness is its incapability of utilizing the entire available bandwidth of a network channel it operates on. This weakness originates from TCPs main advantage which was already mentioned: reliable ordered delivery. To be more precise—a number of mechanisms which provide TCPs reliability, like the sliding window and congestion avoidance mechanisms also contribute to TCP's inefficiency.
TCP's reliable delivery is based on a data acknowledgement mechanism, i.e. each data portion sent is acknowledged by receiver side on receipt. For this purpose, each data portion sent in TCP packet is supplied with Sequence Number which is present in the TCP segment header. Once the data is received, receiver side sends an acknowledgement to data transmitting side by setting an appropriate Acknowledgement Number of backwards TCP segment header. Thus the Acknowledgement Number field of incoming segment indicates the greatest number of data byte which has left the network and was accepted by receiver side. It is obvious that waiting for acknowledgement of every single portion of data before sending another would take too long, that is why a sliding window mechanism is used. TCP specification uses term Send Window Size to indicate the amount of data (in bytes) which can be sent in advance without waiting for acknowledgement. In other words the difference between the Sequence Number of most recently sent data byte and the most recently received Acknowledgement Number must not exceed the Send Window Size value. Once the new acknowledgement is received, the window is shifted and transmission of new data portion is allowed.
This sliding window mechanism is rather simple and provides a possibility of reliable delivery and good throughputs rates at the same time. But an obvious throughputs upper limitation comes from it: the transmission rate is limited to Send Window Size divided by an RTT [bytes/second] value, where RTT is connections Round Trip Time (the time passed from transmission till the acknowledgement of most recently acknowledged data byte). It may easily be seen that the higher RTT (network path latency) is the lower transmission rate may be reached for a particular Send Window Size.
The above limitation is in fact so serious that TCP is hardly ever used as a transport for time critical or performance critical transmissions. Such services as VoIP, which require high transfer rates but are not critical to reliable delivery rather use unreliable but fast UDP transport instead, so do other similar protocols/services.
TCP's performance problems get worse as network bandwidths grow higher. Currently used TCP Send Window Size calculation algorithms often do not allow the utilization of more than 10%-30% of the available bandwidth of broadband connections with 100-200 milliseconds latencies.
Many attempts have been made to overcome the described limitation. They all are based on increasing the send Window Size and keeping it high since there is no way to decrease the present network latencies by manipulating the TCP protocol.
The well known TCP modifications Tahoe, Reno, New Reno and Vegas all propose different ways of Send Window Size calculations and transmission/retransmission control and describe their own TCP behavior algorithms for TCPs main phases: Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery.
TCP Tahoe consequently runs Slow Start and Congestion Avoidance phases. During Slow Start the Congestion Window Size is initially set to Maximum Segment Size and then increased by acknowledged data size on each arriving acknowledgement thus being increased exponentially. The Congestion Window Threshold value is introduced. When Congestion Window Size reaches Congestion Window Threshold, TCP enters the Congestion avoidance phase during which Congestion Window Size is increased linearly (by acknowledged data size divided by Congestion Window Size on each arriving acknowledgement). The Threshold is initially set to Maximum Window Size. On packet loss, the Threshold is set to half of Congestion Window Size and Slow Start Algorithm is involved. The main TCP Tahoe problems significantly degrading its throughputs are late loss detection (Tahoe detects losses by timeouts only) and periodical Slow Start fallback.
TCP Reno keeps the TCP Tahoe's basic concept however a technique called ‘Fast retransmit’ which allows early packet loss detection is introduced. According to the fast retransmit technique, packet loss has to be indicated immediately by remote receiver by the means of multiple duplicate acknowledgements. After immediate packet retransmission TCP Reno does not return to Slow Start but performs a Fast Recovery. Window Threshold and Congestion Window Size are set to half of initial Congestion Window Size. Then Congestion Window Size is increased by MSS on every arriving duplicate acknowledgement and new data transmission is allowed if Congestion Window Size exceeds the currently unacknowledged data size. After performing Fast Recovery which is finished on fresh acknowledgement receipt TCP Reno returns to Congestion Avoidance.
TCP New-Reno inherits TCP Reno mechanisms but implements the modified Fast Recovery phase. The Fast Recovery is not exited until all packets which were sent to the network by the moment of packet loss detection are acknowledged. The partial acknowledgement (not covering the whole amount of data transmitted by the moment of loss detection) is treated as an evidence of successive losses and more packets are retransmitted immediately.
TCP Vegas is a TCP Reno modification. TCP Vegas uses additional congestion avoidance mechanisms based on expected and real bandwidth estimations and adjusts Congestion Window Size in accordance with them. TCP Vegas does also perform an early retransmits before the packet loss is indicated by duplicate acknowledgement initiated by unexpectedly high RTT detection.
The present invention follows none of these techniques but rather uses new technologies to achieve the optimum bandwidth utilization which none of the above modifications are capable of.